Thanks!

ip-api.com

I'd prefer not to hardcode services.

I’m concerned about moving network defense into an audio application, especially via a centralized blocklist. Beyond the performance overhead, this creates a central point of failure and raises privacy issues by sending client IPs to external APIs (once again).

These 'wrecking ball' blocks (ASN/CIDR) risk significant collateral damage and are more precisely managed at the firewall level. Furthermore, the governance of a central 'bad actor' list is an unsolvable problem for a decentralized project—it creates a gatekeeper role that doesn't belong in the Jamulus audio engine.

I’m concerned about moving network defense into an audio application, especially via a centralized blocklist. Beyond the performance overhead, this creates a central point of failure and raises privacy issues by sending client IPs to external APIs (once again).

These 'wrecking ball' blocks (ASN/CIDR) risk significant collateral damage and are more precisely managed at the firewall level. Furthermore, the governance of a central 'bad actor' list is an unsolvable problem for a decentralized project—it creates a gatekeeper role that doesn't belong in the Jamulus audio engine.

I would agree. While anyone is free to create their own fork with modifications to support their use case, I'm not convinced this kind of functionality belongs within Jamulus itself.

the governance of a central 'bad actor' list is an unsolvable problem for a decentralized project—it creates a gatekeeper role that doesn't belong in the Jamulus audio engine.

While this is true, we should still think about:

1. How can server admins protect their server from bad actors? There could be valid reasons for this.
2. Server admins should be able to protect themselves from known bad actors - E-Mail servers for example have shared (configurable) blacklists.
3. Can users themselves be enabled to block (?) bad actors? Potentially just for themselves?

the governance of a central 'bad actor' list is an unsolvable problem for a decentralized project—it creates a gatekeeper role that doesn't belong in the Jamulus audio engine.

While this is true, we should still think about:

1. How can server admins protect their server from bad actors? There could be valid reasons for this.
2. Server admins should be able to protect themselves from known bad actors - E-Mail servers for example have shared (configurable) blacklists.
3. Can users themselves be enabled to block (?) bad actors? Potentially just for themselves?

All great examples for implementing @Rob-NY RPC firewall.
It doesn't make external calls, currently only blocks single IPs, could potentially be managed by clients directly via RPC.
Any further protection should be handled at the hoster/OS firewall level.

All great examples for implementing @Rob-NY RPC firewall. It doesn't make external calls, currently only blocks single IPs, could potentially be managed by clients directly via RPC. Any further protection should be handled at the hoster/OS firewall level.

A bad actor should not even reach the application, all of this can be done on firewall level (peek into the UDP payload if it is a jamulus client connect msg, then hand it over to some user space script that does further checking)

See e.g. https://tech-champion.com/ethical-hacking/linux-packet-payload-manipulation-netfilter-and-nfqueue-solutions/

A bad actor should not even reach the application, all of this can be done on firewall level (peek into the UDP payload if it is a jamulus client connect msg, then hand it over to some user space script that does further checking)

See e.g. https://tech-champion.com/ethical-hacking/linux-packet-payload-manipulation-netfilter-and-nfqueue-solutions/

While this is certainly one layer of protection, it doesn't address the ability to dynamically block bad actors after a client join. Not all bad actors are known beforehand. The RPC interface could provide that functionality, and wouldn't necessarily require a server operator or client to learn linux, and nft/iptables (or Mac/PF, Windows Firewall).

@stefan1000 Have you tested the RPC firewall?
You make a valid point about bad actors not reaching the application, but I can tell you based on my own testing that once a block has been implemented on the RPC firewall, the bad actor connection is dropped, can no longer see the server in Connect dialog, nor can any attempt to direct connect succeed. Exactly the same behaviour seen when an OS level firewall rule is implemented.

Your suggestion plus the RPC feature could provide a comprehensive level of protection for servers and users on them.

Ultimately I believe in server admin autonomy in dealing with bad actors, and as @softins previously mentioned, if anyone chooses to modify their servers they can do so. I've always advocated inclusion of the RPC firewall code into the core application, but I understand and respect the desire not to do so.

All great examples for implementing @Rob-NY RPC firewall.
It doesn't make external calls, currently only blocks single IPs, could potentially be managed by clients directly via RPC.
Any further protection should be handled at the hoster/OS firewall level.

I know of two actors who harass groups through a VPN that shifts their IP any time they want. I know of zero actors who harass groups through a singular IP address. That's why I think blocking an single IP is inadequate. And these actors target groups on multiple servers, including servers that are unmonitored. I'd like a defense that would protect against much larger attacks, and multi-IP plus unmonitored servers are facts of life any defense of the larger community needs to cover.

3. Can users themselves be enabled to block (?) bad actors? Potentially just for themselves?

I like the idea of any connection that's mostly-muted (66%+ of other connections?) has their chats silently muted, too.

While anyone is free to create their own fork with modifications to support their use case, I'm not convinced this kind of functionality belongs within Jamulus itself.

Defense and growth of public directory activity isn't everyone's use case, but it's not just my use case! My goal is to provide a custom server until widespread malicious attacks show it's necessary. I know a few server operators who would run a drop-in binary replacement that auto-blocks particular harassers active today. I also know two changes to the client that would improve community discovery, so I'm interested in a fork there, too. I think both long-running, unattended public servers and clients of users active on public servers are two categories that have some unique problems and solutions. Ultimately, I hope to provide these.

I mean technically the App Store guidelines seem to want some moderation features. I hope we'll be able to have client first implementations. This won't harm anyone and empowers users.

All great examples for implementing @Rob-NY RPC firewall.
It doesn't make external calls, currently only blocks single IPs, could potentially be managed by clients directly via RPC.
Any further protection should be handled at the hoster/OS firewall level.

I know of two actors who harass groups through a VPN that shifts their IP any time they want. I know of zero actors who harass groups through a singular IP address. That's why I think blocking an single IP is inadequate. And these actors target groups on multiple servers, including servers that are unmonitored. I'd like a defense that would protect against much larger attacks, and multi-IP plus unmonitored servers are facts of life any defense of the larger community needs to cover.

A jamulus server operator is free to limit access to whatever, just saying this should happen in the network middleware, not in the application.

There a valid use cases for VPNs, also for jamulus, like getting reliable UDP+IPv4 when behind a CGNAT, or avoiding sub-optimal routes because an ISP choose to take a few long latency hops more to not pay for transit.

IP is not an identity, nor is an ASN, it is an ongoing race. If a stronger (or some kind of) user identity is needed, one could require users to authenticate via an OpenID provider (e.g., Google, Apple, Facebook, Amazon, Microsoft) before allowing access.

one could require users to authenticate via an OpenID provider

Something I would rather want to avoid!